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Abstract 


This document describes a profile (a set of required extensions, 
restrictions, and usage modes) of the IMAP and mail submission 
protocols. This profile allows clients (especially those that are 
constrained in memory, bandwidth, processing power, or other areas) 
to efficiently use IMAP and Submission to access and submit mail. 
This includes the ability to forward received mail without needing to 
download and upload the mail, to optimize submission, and to 
efficiently resynchronize in case of loss of connectivity with the 
server. 


The Internet Email to Support Diverse Service Environments (Lemonade) 
profile relies upon extensions to IMAP and Mail Submission protocols; 
specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) 

extensions and the BURL extension to the SUBMIT protocol (RFC 4409). 
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2. 


Introduction 


Lemonade provides enhancements to Internet email to support diverse 
service environments. 


This document describes the Lemonade profile, which includes: 


= "forward without download", which describes exchanges between 
Lemonade clients and servers to allow new email messages to be 
submitted incorporating content that resides on locations 
external to the client. 


— Quick mailbox resynchronization using [CONDSTORE]. 


- Several IMAP and SMTP extensions that save bandwidth and/or 
number of round-trips required to send/receive data. 


The organization of this document is as follows. Section 2 describes 
"forward without download". Section 3 describes additional SMTP 
extensions that must be supported by all Lemonade Submission servers. 
Section 4 describes IMAP quick resynchronization. 


1. Conventions Used in This Document 


In examples, "M:", "I:", and "S:" indicate lines sent by the client 
messaging user agent, IMAP e-mail server, and SMTP submit server, 
respectively. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


All examples in this document are optimized for Lemonade use and 
might not represent examples of proper protocol usage for a general 
use Submit/IMAP client. In particular, examples assume that Lemonade 
Submit and IMAP servers support all Lemonade extensions described in 
this document, so they don’t show how to deal with absence of an 
extension. 


Forward without Download 
1. Motivations 
The advent of client/server email using the [RFC3501], [RFC2821], and 


[SUBMIT] protocols has changed what formerly were local disk 
operations into repetitive network data transmissions. 
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Lemonade "forward without download" makes use of the [BURL] SUBMIT 
extension to enable access to external sources during the submission 
of a message. In combination with the IMAP [URLAUTH] extension, 
inclusion of message parts or even entire messages from the IMAP mail 
store is possible with a minimal trust relationship between the IMAP 
and SMTP SUBMIT servers. 


Lemonade "forward without download" has the advantage of maintaining 
one submission protocol, and thus avoids the risk of having multiple 
parallel and possibly divergent mechanisms for submission. The 
client can use Submit/SMTP [SUBMIT] extensions without these being 
added to IMAP. Furthermore, by keeping the details of message 
submission in the SMTP SUBMIT server, Lemonade "forward without 
download" can work with other message retrieval protocols such as 
Post Office Protocol (POP), Network News Transfer Protocol (NNTP), or 
whatever else may be designed in the future. 


2.2. Message Sending Overview 


The act of sending an email message Can be thought of as involving 
multiple steps: initiation of a new draft, draft editing, message 
assembly, and message submission. 


Initiation of a new draft and draft editing takes place in the Mail 
User Agent (MUA). Frequently, users choose to save more complex 
messages on an [RFC3501] server (via the APPEND command with the 
XDraft flag) for later recall by the MUA and resumption of the 
editing process. 


Message assembly is the process of producing a complete message from 
the final revision of the draft and external sources. At assembly 
time, external data is retrieved and inserted in the message. 


Message submission is the process of inserting the assembled message 
into the [RFC2821] infrastructure, typically using the [SUBMIT] 
protocol. 


2.3. Traditional Strategy 
Traditionally, messages are initiated, edited, and assembled entirely 
within an MUA, although drafts may be saved to an [RFC3501] server 


and later retrieved from the server. The completed text is then 
transmitted to a Message Submission Agent (MSA) for delivery. 
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There is often no clear boundary between the editing and assembly 
process. If a message is forwarded, its content is often retrieved 
immediately and inserted into the message text. Similarly, when 
external content is inserted or attached, the content is usually 
retrieved immediately and made part of the draft. 


As a consequence, each save of a draft and subsequent retrieve of the 
draft transmits that entire (possibly large) content, as does message 
submission. 


In the past, this was not much of a problem, because drafts, external 
data, and the message submission mechanism were typically located on 
the same system as the MUA. The most common problem was running out 
of disk quota. 


2.4. Step-by-Step Description 
The model distinguishes among a Mail User Agent (MUA), an IMAP4Rev1 


Server ([RFC3501]), and a SMTP submit server ([SUBMIT]), as 
illustrated in Figure 1. 


a a ca oa cat ts + ta Sanaasss=sso + 
| [ss | | 
| MUA (M) | | IMAPv4Rev1 | 
| | | Server | 
| | ------------ > | (Server I) | 
+-------------------- + +-------------- + 
| | | 
u U | | 
| H | | 
| | | | 
| | | | 
ma E 
+-------------- + 
| | ---------------------- > | SMTP | 
| | Submit | 
|----------------------------- | Server | 
| (Server S) | 
+-------------- + 
Figure 1: Lemonade "forward without download" 


Lemonade "forward without download" allows a Messaging User Agent to 
compose and forward an e-mail combining fragments that are located in 
an IMAP server, without having to download these fragments to the 
client. 
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There are two ways to perform "forward without download", based on 
where the message assembly takes place. The first uses an extended 
APPEND command [CATENATE] to edit a draft message in the message 
store and cause the message assembly on the IMAP server. The second 
uses a succession of BURL and BDAT commands to submit and assemble 
(through concatenation) message data from the client and external 
data fetched from the provided URL. The two subsequent sections 
provide step-by-step instructions on how "forward without download" 
is achieved. 


2.4.1. Message Assembly Using IMAP CATENATE Extension 


In the [BURL]/[CATENATE] variant of the Lemonade "forward without 
download" strategy, messages are initially composed and edited within 
an MUA. The [CATENATE] extension to [RFC3501] is then used to create 
the messages on the IMAP server by transmitting new text and 
assembling them. The [UIDPLUS] IMAP extension is used by the client 
in order to learn the Unique Identifier (UID) of the created 
messages. Finally, a [URLAUTH] format URL is given to a [SUBMIT] 
server for submission using the [BURL] extension. 


The flow involved to support such a use case consists of: 


M: {to I -- Optional} The client connects to the IMAP server, 
optionally starts TLS (if data confidentiality is required), 
authenticates, opens a mailbox ("INBOX" in the example below) and 


fetches body structures (See [RFC3501]). 


Example: 


M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE) 


I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" 
("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23) ( 
"TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" 
"trip.txt") 


"<960723163407.20117h@washington.example.com>" 
"Your trip details" "BASE64" 4554 73) "MIXED")) 
I: A0051 OK completed 


M: {to I} The client invokes CATENATE (See [CATENATE] for details 
of the semantics and steps) -- this allows the MUA to create 
messages on the IMAP server using new data combined with one or 
more message parts already present on the IMAP server. 


Note that the example for this step doesn't use the LITERAL+ 
[LITERAL+] extension. Without LITERAL+, the new message is 
constructed using 3 round-trips. If LITERAL+ is used, the new 
message Can be constructed using one round-trip. 
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g 


A0052 APPEND Sent FLAGS (\Seen ŠMDNSent) 

CATENATE (TEXT {475} 

+ Ready for literal data 

Message-ID: <419399F1.6000505@caernarfon.example.org> 

Date: Thu, 12 Nov 2004 16:57:05 +0000 

From: Bob Ar <bar@example.org> 

MIME-Version: 1.0 

To: foo@example.net 

Subject: About our holiday trip 

Content-Type: multipart/mixed; 
boundary="------------ 030308070208000400050907" 


RRA === 030308070208000400050907 
Content-Type: text/plain; format=flowed 


Our travel agent has sent the updated schedule. 


Cheers, 

Bob 

Ss SSSS S555 25> 030308070208000400050907 

URL "/INBOX; UIDVALIDITY=385759045/; 
UID=25627/;Section=2.MIME" URL "/INBOX; 
UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44} 
I: + Ready for literal data 


SSSS SESS SESE SESS SSESESE SH 


Ms s=======-S==== 030308070208000400050907-- 
I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed 


M: (to 1) The client uses GENURLAUTH command to request a URLAUTH 
URL (see [URLAUTH]). 


I: {to M} The IMAP server returns a URLAUTH URL suitable for later 
retrieval with URLFETCH (see [URLAUTH] for details of the 
semantics and steps). 


M: A0054 GENURLAUTH "imap://bob.ar@example.org/Sent; 
UIDVALIDITY=387899045/; uid=45; expire=2005-10- 
28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL 

I: * GENURLAUTH "imap://bob.ar@example.org/Sent; 
UIDVALIDITY=387899045/; uid=45; expire= 
2005-10-28T23:59:59Z;urlauth=submit+bob.ar: 
internal: 91354a473744909de610943775£92038" 

I: A0054 OK GENURLAUTH completed 


M: {to SJ The client connects to the mail submission server and 


starts a new mail transaction. It uses BURL to let the SMTP 
submit server fetch the content of the message from the IMAP 
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server. (See [BURL] for details of the semantics and steps.) 

This allows the MUA to authorize the SMTP submit server to access 
the message composed as a result of the CATENATE step. Note that 
the second EHLO command is required after a successful STARTTLS 
command. Also note that there might be a third required EHLO 
command if the second EHLO response doesn’t list any BURL options. 
Section 2.4.2 demonstrates this. 


220 owlry.example.org ESMTP 
EHLO potter.example.org 
250-owlry.example.com 
250-8BITMIME 
250-BINARYMIME 
250-PIPELINING 

250-BURL imap 
250-CHUNKING 

250-AUTH PLAIN 

250-DSN 
250-SIZE 10240000 

250-STARTTLS 

250 ENHANCEDSTATUSCODES 

STARTTLS 

220 Ready to start TLS 

.TLS negotiation, subsequent data is encrypted... 

EHLO potter.example.org 

250-owlry.example.com 

250-8BITMIME 

250-BINARYMIME 

250-PIPELINING 

250-BURL imap 

250-CHUNKING 

250-AUTH PLAIN 

250-DSN 

250-SIZE 10240000 

250 ENHANCEDSTATUSCODES 

AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= 

235 2.7.0 PLAIN authentication successful. 

MAIL FROM:<bob.ar@example.org> 

250 2.5.0 Address Ok. 

RCPT TO:<foo@example.net> 

250 2.1.5 foo@example.net OK. 

BURL imap://bob.ar@example.org/Sent ; UIDVALIDITY=387899045/; 
uid=45/;urlauth=submit+bar:internal: 
91354a473744909de610943775£92038 LAST 


NAZNNNNNHNHNHNHNHHNN Zu 


SHEN ZHZTNUNHNNNNnNHNNHNN EZ: 
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S: {to I} The mail submission server uses URLFETCH to fetch the 
message to be sent. (See [URLAUTH] for details of the semantics 
and steps. The so-called "pawn-ticket" authorization mechanism 
uses a URI that contains its own authorization credentials.) 


I: {to S} Provides the message composed as a result of the 
CATENATE step. 


Mail submission server opens IMAP connection to the IMAP server: 


I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ 
CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com 
IMAP server ready 

S: a000 STARTTLS 

I: a000 Start TLS negotiation now 
.TLS negotiation, if successful - subsequent data 
is encrypted... 

S: a001 LOGIN submitserver secret 

I: a001 OK submitserver logged in 

S: a002 URLFETCH "imap://bob.ar@example.org/Sent; 
UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar: 
internal:91354a473744909de610943775f£92038" 

I: * URLFETCH "imap://bob.ar@example.org/Sent; 

UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar: 

internal:91354a473744909de610943775f£92038" (15065) 

.message body follows... 

a002 OK URLFETCH completed 

a003 LOGOUT 

* BYE See you later 
a003 OK Logout successful 


NNHNs 


Note that if the IMAP server doesn’t send CAPABILITY response code 
in the greeting, the mail submission server must issue the 
CAPABILITY command to learn about supported IMAP extensions as 
described in RFC 3501. 


Also, if data confidentiality is not required, the mail submission 
server may omit the STARTTLS command before issuing the LOGIN 


command. 


S: {to M} Submission server assembles the complete message, and if 
the assembly succeeds, it returns OK to the MUA: 


S: 250 2.5.0 Ok. 


M: {to I} The client marks the message containing the forwarded 
attachment on the IMAP server. 
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M: A0053 UID STORE 25627 +FLAGS.SILENT (SForwarded) 
* 215 FETCH (UID 25627 MODSEQ (12121231000) ) 
I: A0053 OK STORE completed 


H 


Note: the UID STORE command shown above will only work if the 
marked message is in the currently selected mailbox; otherwise, it 
requires a SELECT. This command can be omitted. The untagged 
FETCH response is due to [CONDSTORE]. The $Forwarded IMAP keyword 
is described in Section 2.8. 


2.4.2. Message Assembly Using SMTP CHUNKING and BURL Extensions 


In the [BURL]/[CHUNKING] variant of the Lemonade "forward without 
download" strategy, messages are initially composed and edited within 
an MUA. During submission [SUBMIT], BURL [BURL] and BDAT [CHUNKING] 
commands are used to create the messages from multiple parts. New 
body parts are supplied using BDAT commands, while existing body 
parts are referenced using [URLAUTH] format URLs in BURL commands. 


The flow involved to support such a use case consists of: 


M: {to I -- Optional} The client connects to the IMAP server, 
optionally starts TLS (if data confidentiality is required), 
authenticates, opens a mailbox ("INBOX" in the example below), and 


fetches body structures (see [RFC3501]). 


Example: 


M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE) 


I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" 
("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23) ( 
"TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" 
"trip.txt”) 


"<960723163407.20117h@washington.example.com>" 
"Your trip details" "BASE64" 4554 73) "MIXED") ) 
I: A0051 OK completed 


M: (to 1) The client uses GENURLAUTH command to request URLAUTH 
URLs (see [URLAUTH]) referencing pieces of the message to be 
assembled. 


I: {to M} The IMAP server returns URLAUTH URLs suitable for later 
retrieval with URLFETCH (see [URLAUTH] for details of the 
semantics and steps). 


M: A0054 GENURLAUTH "imap://bob.ar@example.org/INBOX; 


UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" 
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INTERNAL "imap://bob.arđexample.org/INBOX; 
UIDVALIDITY=385759045/; UID=25627/; Section=2; 
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL 

I: * GENURLAUTH "imap://bob.arđexample.org/INBOX; 
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 
internal:A0DEAD473744909de610943775f9BEEF" 
"imap://bob.artexample.org/INBOX; 
UIDVALIDITY=385759045/; UID=25627/; Section=2; 
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 
internal : BEEFAODEAD473744909de610943775f9" 

I: A0054 OK GENURLAUTH completed 


M: (to S} The client connects to the mail submission server and 
starts a new mail transaction. It uses BURL to instruct the SMTP 
submit server to fetch from the IMAP server pieces of the message 
to be sent (see [BURL] for details of the semantics and steps). 
Note that the second EHLO command is required after a successful 
STARTTLS command. The third EHLO command is required if and only 
if the second EHLO response doesn’t list any BURL options. See 
Section 2.4.1 for an example of submission where the third EHLO 
command/response is not present. 


220 owlry.example.org ESMTP 
EHLO potter.example.org 
250-owlry.example.com 
250-8BITMIME 

250-BINARYMIME 
250-PIPELINING 

250-BURL 

250-CHUNKING 

250-AUTH DIGEST-MD5 

250-DSN 

250-SIZE 10240000 
250-STARTTLS 

250 ENHANCEDSTATUSCODES 
STARTTLS 

220 Ready to start TLS 

.TLS negotiation, subsequent data is encrypted... 
EHLO potter.example.org 
250-owlry.example.com 
250-8BITMIME 

250-BINARYMIME 
250-PIPELINING 

250-BURL 

250-CHUNKING 

250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL 
250-DSN 


NAZNNNNNHHNnNHUnNN EN 


vnnaunnnnan Z- 
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250-SIZE 10240000 
250 ENHANCEDSTATUSCODES 
AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= 
235 2.7.0 PLAIN authentication successful. 
EHLO potter.example.org 
250-owlry.example.com 
250-8BITMIME 
250-BINARYMIME 
250-PIPELINING 
250-BURL imap imap://imap.example.org 
250-CHUNKING 
250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL 
250-DSN 
250-SIZE 10240000 
250 ENHANCEDSTATUSCODES 
MAIL FROM:<bob.ar@example.org> BODY=BINARY 
250 2.5.0 Address Ok. 
RCPT TO:<foo@example.net> 
250 2.1.5 foo@example.net OK. 
BDAT 475 
Message-ID: <419399F1.6000505@caernarfon.example.org> 
Date: Thu, 12 Nov 2004 16:57:05 +0000 
From: Bob Ar <bar@example.org> 
MIME-Version: 1.0 
To: foo@example.net 
Subject: About our holiday trip 
Content-Type: multipart/mixed; 
boundary="------------ 030308070208000400050907" 


RRA RRA 030308070208000400050907 
Content-Type: text/plain; format=flowed 


Our travel agent has sent the updated schedule. 


SES SS 030308070208000400050907 

250 2.5.0 OK 

BURL imap://bob.ar@example.org/INBOX; 

UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 

expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 

internal:A0DEAD473744909de610943775f9BEEF 

S: 250 2.5.0 OK 

M: BURL imap://bob.ar@example.org/INBOX; 
UIDVALIDITY=385759045/; UID=25627/; Section=2; 
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 
internal : BEEFAODEAD473744909de610943775£9 

S: 250 2.5.0 OK 


SNESSEESESSESSE SS ES ESSE ES ENENENNNHNNHNHNNNNENENVNN 
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M: BDAT 44 LAST 


a E E 030308070208000400050907-- 


S: {to I} The mail submission server uses URLFETCH to fetch the 
pieces of the message to be sent (see [URLAUTH] for details of the 


semantics and steps). The so-called "pawn-ticket" authorization 
mechanism uses a URI that contains its own authorization 
credentials. 


I: {to S} Returns the requested body parts. 


Mail 


H 


NNHNs 


submission server opens IMAP connection to the IMAP server: 


* OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ 

CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com 

IMAP server ready 

a001 LOGIN submitserver secret 

a001 OK submitserver logged in 

a002 URLFETCH "imap://bob.ar@example.org/INBOX; 

UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 

expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 

internal:A0DEAD473744909de610943775f9BEEF" "imap:// 

bob.arđexample.org/INBOX; 

UIDVALIDITY=385759045/;UID=25627/;Section=2; 

expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 

internal:BEEFA0DEAD473744909de610943775f9" 

* URLFETCH "imap://bob.ar@example.org/ INBOX; 

UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 

expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 

internal:A0DEAD473744909de610943775f9BEEF" {84} 

.message section follows... 
"imap://bob.artexample.org/INBOX; 

UIDVALIDITY=385759045/; UID=25627/; Section=2; 

expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 

internal:BEEFA0DEAD473744909de610943775f9" {15065} 

.message section follows... 

a002 OK URLFETCH completed 

a003 LOGOUT 

* BYE See you later 

a003 OK Logout successful 


Note that if the IMAP server doesn't send CAPABILITY response code 
in the greeting, the mail submission server must issue the 
CAPABILITY command to learn about supported IMAP extensions as 
described in RFC 3501. 
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Also, if data confidentiality is required, the mail submission 
server should start TLS before issuing the LOGIN command. 


S: {to M) Submission server assembles the complete message, and if 
the assembly succeeds, it acknowledges acceptance of the message 
by sending 250 response to the last BDAT command: 


S: 250 2.5.0 Ok, message accepted. 


M: (to 1) The client marks the message containing the forwarded 
attachment on the IMAP server. 


M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded) 
I: * 215 FETCH (UID 25627 MODSEQ (12121231000)) 
I: A0053 OK STORE completed 


Note: the UID STORE command shown above will only work if the 
marked message is in the currently selected mailbox; otherwise, it 
requires a SELECT. This command can be omitted. The untagged 
FETCH response is due to [CONDSTORE]. The $Forwarded IMAP keyword 
is described in Section 2.8. 


2.5. Normative Statements Related to Forward without Download 
Lemonade-compliant IMAP servers MUST support IMAP4Rev1 [RFC3501], 


CATENATE [CATENATE], UIDPLUS [UIDPLUS], and URLAUTH [URLAUTH]. This 
support MUST be declared via CAPABILITY [RFC3501]. 


Lemonade-compliant submit servers MUST support BURL [BURL], 8BITMIME 
[8BITMIME], BINARYMIME [CHUNKING], and CHUNKING [CHUNKING]. This 
support MUST be declared via EHLO [RFC2821]. BURL MUST support 
URLAUTH type URLs [URLAUTH], and thus MUST advertise the "imap" 
option following the BURL EHLO keyword (see [BURL] for more details). 


Additional normative statements are provided in other sections. 
2.6. Security Considerations for "pawn-tickets" 


The so-called "pawn-ticket" authorization mechanism uses a URI, which 
contains its own authorization credentials using [URLAUTH]. The 
advantage of this mechanism is that the SMTP submit [SUBMIT] server 
Cannot access any data on the [RFC3501] server without a "pawn- 
ticket" created by the client. 


The "pawn-ticket" grants access only to the specific data that the 


SMTP submit [SUBMIT] server is authorized to access, Can be revoked 
by the client, and can have a time-limited validity. 
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7. 


8. 


The fcc Problem 


The "fcc problem" refers to delivering a copy of a message to a "file 
carbon copy" recipient. By far, the most common case of fcc is a 
client leaving a copy of outgoing mail in a "Sent Mail" or "Outbox" 
mailbox. 


In the traditional strategy, the MUA duplicates the effort spent in 
transmitting to the MSA by writing the message to the fcc destination 
in a separate step. This may be a write to a local disk file or an 
APPEND to a mailbox on an IMAP server. The latter is one of the 
"repetitive network data transmissions" that represents the "problem" 
aspect of the "fcc problem". 


The [CATENATE] extension to [RFC3501] can be used to address the fcc 
problem. The final message is constructed in the mailbox designed 
for outgoing mail. Note that the [CATENATE] extension can only 
create a single message and only on the server that stages the 
outgoing message for submission. Additional copies of the message 
can be created on the same server using one or more COPY commands. 


Registration of $Forwarded IMAP Keyword 


The $Forwarded IMAP keyword is used by several IMAP clients to 
specify that the message was resent to another email address, 
embedded within or attached to a new message. A mail client sets 
this keyword when it successfully forwards the message to another 
email address. Typical usage of this keyword is to show a different 
(or additional) icon for a message that has been forwarded. Once 
set, the flag SHOULD NOT be cleared. 


Lemonade-compliant servers MUST be able to store the $Forwarded 
keyword. They MUST preserve it on the COPY operation. The servers 


MUST support the SEARCH KEYWORD $Forwarded. 


Message Submission 


Lemonade-compliant mail submission servers are expected to implement 
the following set of SMTP extensions to make message submission 
efficient. 


Lemonade clients should take advantage of these features. 
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3.1. Pipelining 


Mobile clients regularly use networks with a relatively high latency. 
Avoidance of round-trips within a transaction has a great advantage 
for reduction in both bandwidth and total transaction time. For this 
reason, Lemonade-compliant mail submission servers MUST support the 
SMTP Service Extensions for Command Pipelining [RFC2920]. 


Clients SHOULD pipeline SMTP commands when possible. 


3.2. DSN Support 


Lemonade-compliant mail submission servers MUST support SMTP service 
extensions for delivery status notifications [RFC3461]. 


3.3. Message Size Declaration 


Lemonade-compliant mail submission servers MUST support the SMTP 
Service Extension for Message Size Declaration [RFC1870]. 


Lemonade-compliant mail submission servers MUST "expand" all BURL 
parts before enforcing a message size limit. 


A Lemonade-compliant client SHOULD use message size declaration. In 
particular, it MUST NOT send a message to a mail submission server, 
if the client knows that the message exceeds the maximal message size 
advertised by the submission server. 


3.4. Enhanced Status Code Support 


Lemonade-compliant mail submission servers MUST support SMTP Service 
Extension for Returning Enhanced Error Codes [RFC2034]. 


3.5. TLS 


Lemonade-compliant mail submission servers MUST support SMTP Service 
Extension for Secure SMTP over TLS [SMTP-TLS]. 


4. Quick Resynchronization 
Lemonade-compliant IMAP servers MUST support the CONDSTORE 
[CONDSTORE] extension. It allows a client to quickly resynchronize 
any mailbox by asking the server to return all flag changes that have 


occurred since the last known mailbox synchronization mark. 


[IMAP-DISC] shows how to perform quick mailbox resynchronization. 
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5. Additional IMAP Extensions 


Lemonade-compliant IMAP servers MUST support the NAMESPACE 
[NAMESPACE] extension. The extension allows clients to discover 
shared mailboxes and mailboxes belonging to other users. 


Lemonade-compliant IMAP servers MUST support the LITERAL+ [LITERAL+] 
extension. The extension allows clients to save a round-trip each 
time a non-synchronizing literal is sent. 


Lemonade-compliant IMAP servers MUST support the IDLE [IDLE] 
extension. The extension allows clients to receive instant 
notifications about changes in the selected mailbox, without needing 
to poll for changes. 


Lemonade-compliant IMAP servers MUST support IMAP over TLS [RFC3501] 
as required by RFC 3501. 


6. Summary of the Required IMAP and SMTP Extensions 


| PIPELINING Section 3.1 

[AA psn ss section 3.2 | 
e section 3.3 
| ENHANCEDSTATUSCODES | section 3.4 | | 
a section 3.5 | 


Section 2.5 | 


| CHUNKING, Section 2.5 | 
| BINARYMIME Section 2.5 

| 8BITMIME, Required by BURL 

| AUTH Required by Submission, | 


See [SMTPAUTH]. | 


| 
| 
| 
| 
| 
| 
| BURL | Forward without download, 
| 
| 
| 
| 
| 
| 
| 
| 
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8. 


| SForwarded IMAP keyword 


Future work 


| 
| Name of IMAP extension | Comment 
| or feature | | 
| NAMESPACE | Section 5 
|------------------------- |-------------------------- | 
| CONDSTORE | Section 4 | 
|------------------------- |-------------------------- | 
| STARTTLS Required by IMAP ee 
| URLAUTH, | Forward without download, | 
| CATENATE, | Section 2 | 
| UIDPLUS | | 
| ------------------------- | -------------------------- | 
| LITERAL+ | Section 5 | 
| IDLE | Section 5 | 
| | 
| | 
| | 


June 2006 


The Lemonade Working Group is looking into additional issues related 


to usage of email by mobile devices, possibly including: 


- Media conversion (static and possibly streamed) 


— Transport optimization for low or costly bandwidth and less 


reliable mobile networks (e.g., quick reconnect) 


— Server to client notifications, possibly outside of the 


traditional IMAP band 
- Dealing with firewall and intermediaries 
- Compression and other bandwidth optimization 
- Filtering 
— Other considerations for mobile clients 


Security Considerations 


Security considerations on Lemonade "forward without download" are 
discussed throughout Section 2. Additional security considerations 
can be found in [RFC3501] and other documents describing other SMTP 


and IMAP extensions comprising the Lemonade profile. 


Note that the mandatory-to-implement authentication mechanism for 


SMTP submission is described in [SUBMIT]. The mandatory-to- 


authentication mechanism for IMAP is described in [RFC3501]. 
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8.1. Confidentiality Protection of Submitted Messages 


When clients submit new messages, link protection such as TLS guards 
against an eavesdropper seeing the contents of the submitted message. 
It’s worth noting, however, that even if TLS is not used, the 
security risks are no worse if BURL is used to reference the text 
than if the text is submitted directly. If BURL is not used, an 
eavesdropper gains access to the full text of the message. If BURL 
is used, the eavesdropper may or may not be able to gain such access, 
depending on the form of BURL used. For example, some forms restrict 
use of the URL to an entity authorized as a submission server or a 
specific user. 


8.2. TLS 


When Lemonade clients use the BURL extension to mail submission, 
which requires sending a URLAUTH token to the mail submission server, 
such a token should be protected from interception to avoid a replay 
attack that may disclose the contents of the message to an attacker. 
TLS-based encryption of the mail submission path will provide 
protection against this attack. 


Lemonade clients SHOULD use TLS-protected IMAP and mail submission 
channels when using BURL-based message submission to protect the 
URLAUTH token from interception. 


Lemonade-compliant mail submission servers SHOULD use TLS-protected 
IMAP connections when fetching message content using the URLAUTH 
token provided by the Lemonade client. 


When a client uses SMTP STARTTLS to send a BURL command that 
references non-public information, there is a user expectation that 
the entire message content will be treated confidentially. To meet 
this expectation, the message submission server should use STARTTLS 
or a mechanism providing equivalent data confidentiality when 
fetching the content referenced by that URL. 
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